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Acstract 



In tnis paper we investigate the robustness of several ieadlcck 
detection algorithms for distributed computing 37 /stems. \Ie analyze 
the behavior of each algorithm in the presence of mwo classes of 
failures - lost messages and single site failures. In the case of 
single site fail'ure we consider six different tyres of sites iependins 
on how they cem participate in deadlock and deadlock detection. The 
observation and ccncl’tsions made in this taper are intended to show 
how robust the present -algorithcns are and to provide an insignt and 
better 'onderstandins of distributed alsoritlnms robustness. 



ZITRCDUCTIC::. 



-here have been 'aany alr:crihh!nE published for deadlock detection, 
prevention or avoidance in centralized multiprogramming systems. The 
problem of deadlock in those systems has been essentially solved. In 
the past decade there has been considerable work done on distributed 
iomruter ney.vcrks and multirrocessor r'stems. loth of these are 



'edecessors :f distributed ocmputing systems which are presently a 



fccus of intensive researcn and development in academia and industry. 
Many techniques for concurrency control, reliability/recovery or secu- 
rity developed for centralized (or single CPU) systems have been or 
are being adopted and adapted for distributed computing systems. For 
example, there is a tendency to use locking as a general synchroniza- 
tion techni'pue in distributed systems and its special variant, two- 
phase locking, for distributed database systems. Up until recently it 
has been arg>aed that the frequency of deadlock occurence in existing 
applications is so low that the problem of deadlock in distributed 
systems is not very important and therefore can be managed by adopting 
techniques developed for ce.ntralized systems. However, it has become 
recently apparent that ieadlocks ma,y be a problem in the future as we 
see new applications featuring large processes and/or many concurrent 
processes or transact! ons f ] . As -an example of such new applica- 
tions we mention information utility systems which service conc’orrent- 
ly hundreds or perhans thousands of Ui -csers. 
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the last t'.vo items raise the problems of deadlock occurence in distri- 
buted systems, and the first two characteristics of distributed sys- 
tems make it mucn more difficult to detect, avoid or prevent than in 
the earlier rculti programming centralized computing systems. 

Deadlock prevention and avoidance algoritlams for a distributed 
computing systems are not efficient. Prevention can be accomplished 
by not allowing concurrent processing, by assigning priorities and 
allowing preemption, by requiring a process to a.cquire all resou,rces 
it will need before it starts, cr by having no locks. Peopairing 
sequential execution in a distributed system is a gross waste of 
resources . Having prioritized processes will result in lower- 



prioritied processes being restarted many tines, with a major degrada- 
tion in system efficiency. D’mamic prioritization would be a complex 
algorithm by itself. A process may be lanable to determine its minimitn 
set of resources, and therefore would have to acquire the set of all 
probable and possible resources, even though it may not need them. In 
addition, in systems in which messages are treated as resources, it is 
impossible to determine in advance which messages will be required. 
Having no locks may result in database inconsistencies, assioming a 



non-optimistic concurrency controller. Similarly, deadlock avoidance 
algorithms, which either calculate a 'safe path' ['1C177] or never wait 
for a lcck'_ 1?-A'~S] are also inefficient. Safe path algoritlnms require a 
non-trivial execution time, and m'ust '■'e done each time a resource 
request is to be gran'^ed. 'lever waiting for a lock is inefficient 
whe.n deadloc'x is a rare occurence. Ihus, in distributed commuting 
systems, deadlock detec~icn and resolution algorithms ~ust be used. 
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robustness, 3) performance, and 4-) practicality. Correctness refers 
^0 the ability of the algorithm to ietect all ieadlocks, and “he abil- 
ity to not ietect any false ieadlocks. Robustness refers to the abili- 
ty of the algorithm to be correct even in the presence of anticipated 
faults. Chis includes the ability to detect deadlocks even when a 
site fails or loses communications while the deadlock detection algo- 
rithm is being executed. Che performance of the algorithm refers to 
its overhead - the dela,ys bem'/een deadlock and detection, CPU time 
used, number of messages required, etc. Practicality is closely re- 
lated to performance. It refers to aspects such as complexity and 
cost . 

Several different approaches are being used in current deadlock 
detection and resolution algorithims for distributed systems. U^o major 
ones are centralized and distributed deadlock detection algorithms. 
Within the distributed class are two subclasses; 1 ) all or several 
sites execute the deadlock detection algorithm, and 2' only one site 
is actually executing, although the algorithm is resident in all sites 
and thus any site could execute the algorithm. It mimht be easier to 
view the algorithms as a continuum: fully centralizedrCRA'^S] , 
hierarchical[MUr79j , distributed with a single site at a time execut- 
ing the algoritha[lCL77] , distributed with all sites involved in a 
possible deadlock executing the algorithm concur rentlyyHT'?'' . and 
distributed with all sites executing the algorithm 
concurrently[l3L'78l . 

In this paper we investigate the robustness of sever?.! published 
deadlock detecticn and resolution algorithms for distri'’:uted systems. 
Ihe motivation for our wort oomes from three facts, first, ver” few 
authors i.nvesti^rated robustness or '’eliabili—' of deadlock detec'ion 



algorithms. Second, reliable deadlock detection and resolution for 
upcoming new distributed systems and applications is in our opinion an 
■•argent, very important and as yet not satisfactorily resolved problem. 
Third, as there can be more than one deadlock being detected by the 
deadlock detection algorithm then it is reasonable to expect such 
algorithm to be robust, i.e., to continue executing and detecting all 
deadlocks even in the tresence of failureis' '.■/hich mish.t have in ef- 
fect creaked one of the deadlocks being detected. 

The paper is organised as follows. In section t'/io, we discuss 
robiastness of distributed 35rstems. In section three, we analyze the 
robustness of several existing deadlock detection algorithms with 
respect to some single failures. In section four, we present our con- 
cliasions based on the analysis of section 3- 

II. SOMI THOUC-HTS ON ROEUSHISSS DI DISTRIBUTH) OYSTH'IS. 

In this paper we want to investigate the robustness of deadlock 
detection algorithms (DDA\ i.e., we 'want to find out the impact of 
some single failures on such algorithms. In general, the DBA is in- 
'/oked b'A t'wo events - either whenever a process v/aits for a resoitrce, 
or after a certain period of time has elapsed since the last ODA invo- 
cation. In the first case, deadlock is checked for whenever its pos- 
sibility,' aptears, and in the second oase it is checked for teriodical- 
ly 'i.e., regardless of v/hether its possibility exists''. 

The IDA can reside in one, several or all sites of the distribut- 
ed computing system. v/hen a tri,^ering event for TDA occurs, then 
depending on a particular algorithm one, several or all sites will 
recei'/e inoTormation from several or all sites. Such information con- 
sists of "’.vho waits for whom and wnere", and it can be represented by 






arcs cf ^he vait-for graph, strings, or lists of processes or transac- 
ti'^ns. fpon receipt of such inforoiation one, several or all sites 
attempt to reconstruct a global state of the distributed system, i.e., 
to generate a true snapshot of all or of all waiting processes in the 
system. 

Ihe generation of such a true snapshot in the distributed system 
is difficult because of lack of global memcry and the message delays 
which are not neglibible and can vary considerably. Ihe generation of 
such a true snapshot, usually referred to as a global wait-for graph, 
becomes even more difficult when we consider a possibility of failures 
in the distributed S3rstem. Some system mechanisms have been designed 
to be robust or reliable. For example, some concurrency control or 
synchronization mechanisms for distributed databases and transaction 
processing systems are based on tivo phase locking, 'vhich has been made 
robust by incorporating atomicit:/ by ’osing two phase commit protocols. 
She two chase commit protocol supports not only the atomicity of tran- 
sactions but also it supports the robustness of locking, i.e., the 
robustness of ccncurrenc.y control mechanisms. In particular what 
makes the conc’orrency control which 'jses Icckine robust is the need to 
lock and 'onlock resctirces in a robust way, i.e., either all 
lock/ionlock cperations for a given process or transaction occur or 
none occur. Ihras in seme sense, the robustness of concurrency control 
is meant to support the atomicit:/' of placing and releasing a set of 
locks needed b:/ a process. In other '.vords, the robustness of con- 
currency control m:eans that no dangling locks or locked resources are 
left behind the terminated or committed trccess, even in ~he '.oresence 
-- seme failures. It is interesting: to note that althousn deadlock 



been no attempt to provide for or even to invest i^te the robustness 
of ieadlock detection mechanisms, fhe most likely explanation for 
this is that from the concurrency control point of view, the inability 
of the process to lock a needed resource is an exception to be handled 



by another mechanism, i.e., a deadlock detection algorithm (IDA'). 

Ihe proper way to see the IDA is as another transaction roTining 
under the concurrency control mechanism, as it reads 'and shares lock 



tables with concurrency controllers and other transactions. However, 
DDA is a special transaction which operates on special data it creates 
solely for deadlock detection, e.g., wait-for graphs. Such data, 
we'll call it deadlock data, is internal to each invocation of DDA 
transaction and is erased after its execution. Moreover, such 
deadlock data is not shared by any other DDA transaction invocations 
and therefore they need not be locked. This means that the robustness 
required of DDA transactions is of a somewhat different kind than the 
robustness of transactions operating on shared database data. Dhrus it 
makes sense that the DDA transaction does not need to use kwo phase 
commit to assure its robustness. Dhe ^^uesticn then is what kind of 
robustness or fault-tolerance we need for DDA transactions and this is 
precisely the problem we are addressing in this paper. 

’.ve consider the folloxiring i.nformal model of DDA transaction exe- 
cution. Dhe DDA is invoked by a concurrency controller at a site at 
which a database transaction can not acquire locks which are being 
held by another transaction(s) . Dhe DDA transaction executes at one, 
several, or -all sites 'depending on the DDA itself and the deadlock 
topology . During its execution the DDA transaction should exhibit 
the atomicity proper'H,^, i.e., it either executes correctly or it does 
not execute at all. Dhe results cf DDA transaction execution are kwo 



•messages to the concurrency controller which has triggered it: 

’ ' Proceed - because of a) no deadlock 

b ' deadlock detected ''^ut another 
transaction v/as selected as 
a victim for back-up 

2) Abort - because of a) deadlock detected and you are 

the victim. 

b') IDA transaction failed, i.e., 
it did not execute. 

Dhe situation we investigate in this paper is when DDA transac- 
tions fail or should not fail, i.e., how robust the existing DDA's are 
or should be. In this paper v/e consider only yvo classes of single 
failures. First, we investigate the impact of lost messages and 
second, we investigate the impact of one site failures, or identically 
one site partitions on DDA behavior. We investigate the impact of lost 
messages because not all distributed systems may support reliable 
delivery of messages, several algorithms treat messages as 
resources r G0L77 ] , and in some applications, acknowledgements cannot be 
sent. 



III. RELIABILITY AITALYSIS OF DE4DLCCX DETBCTICN .ALGCRITHT'IS 

In this section, we examine four published deadlock detection 
algorithns for distributed computing systems with respect to the pres- 
ence of the two classes of failures 'lost messages and site failures) 
disc’Jisssd in section two. Although very few of them have already been 
shc^^i to be correct when no failures or errors occur, we feel that 
their robustness is nevertheless worth analyzing. The assumptions 
made by each author will be discussed in the context of how robust the 
algorithm is. We will analyze each DDA ’ 03 ; executing it in the follow- 
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rescurce and a single transaction. Ihese restrictions nerely aake the 



example simpler, they are not required for the analysis.' Ihe initial 
system status is shewn in figure 1 . Transaction T1 at site A holds 
resources R2 and RJ> and is waiting for resource R4. Transactions T2 
.and T3 hold no resources. Transaction T4 at site D holds resource R4, 
but is active. We assume that the deadlock ietection activity result- 
ing from T1 waiting for R4 has been completed, so there is currently 
no deadlock detection activit:/’ in the system. ?or the algorithms 
which require global timestamps, we assign timest.amp ^'T2' t1 to the 
T1< — ?2 assignment, t2 to the T4< — R4 assignment, t3 to the T1 < — R3 
assignment, and t4 to the T" — >R4 request. Mow at some time t6, tran- 
saction T4 requests RJ, resulting in a global deadlock T1 — >T4 — >T1 . 

Site A Site 3 Site C Site D 

"t-j rri2 71^ 




T 

R3 R4 

1 ^ T 

I . , ' 



+ 



Figure 1 



In the case of a site failure, we distinguish the following cases, a) 
.A site can have a transaction involved in a deadlock but not be in- 
volved in ieadlcck detection, b' a site can have a transaction in- 
volved in a deadlock and be involved in detection, c ' a site can have 
a resource involved in a deadlock and not be involved in detection, d' 
a site can have a resource involved in a deadlock and be involved in a 
detection, or e) a site can be involved in deadlock detection but in 
no way involved in a deadlock. Mot all of these possibilities exist 
witn each algorithm. 

tewe ^ 



A. -HE DISTRIBUTED DEADLOCK DZTECTICII ALCC^RITHI^ DP UCLDIUU;. 

In [GCL'^'^], Goldman presents t.-;o deadlock detection algc- 
rithms. Only the distributed version will be considered in this pa- 
per. A Process Management iModule (PW) at each site handles resource 
allocation and deadlock detection. .An 'ordered blocked process list' 
(OEPL) is a list of process names, each of which is waiting for access 
to a resource assigned to the preceeding process in the list. The 
last process in the list is either waiting for access to the resource 
named, or it has access to th.at resource. An DEPL is created each 
time a PMId wants to see if a blocked process is involved in a 
deadlock. In the distributed algorithm, an DEPL is passed from a PMi 
to another Pffl which has information either about a resource or a 
transaction in the CEPL which is needed to expand the DEPL. Each PM 
adds the information it Irniows, and either detects a deadlock, detects 
a non-deadlocked state, or passes the CEPL to another P-f'! for further 
expansion. The terms process and transaction will be used 3;;iTicn:'/mou3- 
ly in the analp'sis of this DDA. If several transactions are waiting 
on one transaction, multiple copies may be made of the CEPL and sent 
to each site having one of those ■.^^aiting transactions. Processes can 
be in either of 2 states, active or blocked '^waiting). A blocked pro- 
cess could be waiting for a database object, message text from another 
process or message text from an operator. A process is active if it 
is not blocked. In the algorithm, ?X and EX are tem.porary variables 
representing a process or resource. The steps of the algorithm are: 



Set RK to the value contained in the resource identification 
portion of the CEPL. If PX represents a local resource, go 
to 2. Ctherwise. 20 to 3. 



Verify that the last orocess added to CEPL is 
for PX. If so. go to *. other.fise, halt. 



'vR.l-in.s2 






1 



3. let PX be process controlling R]{. If ?X is already in OBPL, 
then there is a deadlock. If not, go to X. 

X. If PX is local to C’orrent P;€4. go to 3, otherwise go to 

5- If PX is active, there is no deadlock. Discard OBPL and 
halt. Otherwise go to 6. 

6. Add PX to OBPL and go to 10. 

Add PX .and ? 7 . to OBPL. Send OBPL to PWi in site in which PX 
resides. Halt. 

B. Verify that last process in OBPL still has access to ?Ii. If 
not, there is no deadlock, so discard OBPL and salt. If so, 
go to 9. 

If last process in OBPL is active, there is no deadlock, so 
discard CBPL .and halt. Othenirise go to 10. 

10. Call resource for which last process is waiting ?X. If ?Ji is 
local , go to 3 • Otherwise go to 11. 

1 . Place XX in OBPL and send OBPL to PMM of site in which RX 
resides. Halt. 
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Figure 2 shows the actions talcen at each site during the 
of the DDA following the request by 14 for resource P3. Phe 
refer to the current step being executed by the DDA. As can 
the algorititn correctly detected the "ssulting deadlock, in 
orment of no faults. If, however, a tessage is lost I’in cur 
either the OBPL sent fron site C to A, or “he OBPL sen^ fron 
, the r.ecessarr infcruation to detect the deadlock will be 
the alsorithr. v/ill fail to detect an existing deadlock. 



Site A 



Site D 



Site C 

10. Sreate CBPL 'vith 
:i. Set ?:•: = 

3* SI controls R3, 

?1 not in OB?L. 

4. T1 not local 
7. Add SI and R3 to 
OBPL and send 
to site A. 

1 . Set ?:S = R3 . 

3. S1 has access to R3* 

S1 wait ins. 

10. Set r:c ='R4. 

1 1 . Add R4 to CBPL, 

send to site B. 

1 . Set ?:(=R1 . 

2. T1 waitins tor 

R4. 

3. Set ?X=74. 34 
already in CBPL, 
deadlock detected. 

Rigure 2 



C-oldman's algorithm allows the following t:/pes of sites dis- 
cussed previously: type b (a site can have a transaction involved in 
deadlock and the site is involved in detection), t^rce d (a site can 
have a resource held by a transaction involved in deadlock and the 
site will be involved in deadlock detection), and type c 'a site can 
have a resource held by a transaction involved in a deadlock and not 
be involved in deadlock detection' . A site could also be in several 
of the categories above, depending on the complexity of the system 
state. ?or example, site D could be considered a t 3 rce b or type d 
site. If a site of type b ..sites A cr C in our example' fails during 
execution of the IDA, the behavior could be different depending on the 
time of the fail’ure. If the failure secured at site A before site C 
sent the OBPL to site A, site I would realize that site A had failed. 
Ihe algorithm includes no procedure for this occurence, so the 
behavior would be dependent on the 'Jtcderlying system. If the failure 
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:ivity will cease, 



deadlock detection. A systea tiaeout aechanisn would event^ially abort 
the transactions involved in the deadlock. A failure at site D would 
have the same effect as at site A. 

If a site of type d 'site C in our example'/ failed, the time 
of the failure would a^in determine the behavior of the IDA. If the 
failure secured befsre site 1 sent the IDPL to site A, deadlock detec- 
tion activity wc'tld sease wi shout deadlock having been detected. If 
the IBPL had been sent, however, deadlock detection 'would continue at 
sites A and D (sequentially) with site D detecting a deadlock. Ike 
failure of site C would net have been critical after the CBPL had been 
sent. Ihe effect of a type c site fsite 3 in our example) failing 
would have no effect on the behavior of the DDA, because the fact that 
?2 is held by II is not ’osed or kno\wn by the DDA at any site. 

Ihere are essentially two types of DEPL's created by this 
DDA. Ihe first ytpe, call it W, is when a process is '.waitins, but is 
not involved in a deadlock. Ihis OBPL is subsequently discarded. Ihe 
second type, call it D, is one 'which will evenmially show a deadlock 
cycle. If there are n transactions involved in a deadlock c;ocle, this 
DDA ’.will create from '' to n D OEPl's. In our example, only one 
'.was created. If the request by II for resource ?.d hapened sirmultane- 
ously '.with the rec’oest by -- for resource two DEPL’s 'would h.ave 
been created 'which '.would :iave resulted in two sites independently 
detecting the same deadlock, 'uce the one site in our example. Ihus 
the robustness of this algorithm! with respect to a single site failure 
os related to the ratio of the number of D tj/pe DEPL's created to “he 
n’jur.ber of transactions invoLved in ■'rhe deadlock. Ihis ratio is howe’’- 
er de~ermined bv th.e secuencin^ or timi'ns of tra^nsactions messages 



blocked resources. Such sequencing is of random nature. A ratio of 1 



woixLd provide the highest degree of robustness, ’.’/hen only a sin^e 
ISPL is created, the robustness of the DDA is very similar to that of 
a centralised DDA; a single site failure can stop deadlock detection 
activity, ’’/e conclude that the robustness of this DDA can be analyzed 
but it can not be predicted. 



D. DHE MSLIASCD-'TUITDD DISDDIPUDDD ALGCRIDPD'! 

In "enasce and Runtz presented a distri’mited 
deadlock detection algorithm. Dligor and Shattuck [G-LI3C] presented a 
counter example which showed the algorithjn to be incorrect in that it 
failed in some cases to detect a deadlock. They also procosed a 
modification to the algorithm! which they thought would make it 
correct, but they felt the algorithm! was impractical. In [TSA82], 
Tsai and Telford show that the algorithm! as modified by lligor and 
Dhattuck is also incorrect. -levertheless , we will investigate the 
enhanced algorithm '^i.e., its modified version as suggested by lligor 



and Shattuck) in the presence of errors. 

The algorithm constmicts a Transaction->vaits-?or '11*/?) graph 
at originating sites of transactions which are potentially involved in 
the deadlock being detected, and at sites at which some transaction 
could not acquire a resource. Nodes in the ’’/? graphs represent tran- 
sacticns. .An edge 'Ti.T’' indicates that transaction Ti is waiting 
for transaction T.j . .A non-’olccked transaction is a transaction that 
is not waiting and is represented in the ?,vT graph by a node with no 
outgoing arcs. A blocked transaction is waiting for some transaction 
to finish. A 'Slocking set' is defined as the set cf all ncn-blocked 
transactions which can be reached 'ey following a directed path in the 
-h? zhs nods 9.ssoci2.ti0d ':iizh dronsn-coirn d . 



A pair is a 'blocking pair' of T if T' is in the blocking set 
of 1. A 'Potential Blocking set' consists of all waitins transactions 
that can be reached from 1 [ILISC]. Sorig(T) means the site of orisin 



of transaction T. ok is the site c’orrentl.y executing the algorithm. 
The moles which define the enhanced algorithm, as executed as site 3k, 
are: 



Rule 0: 'men a transaction T requests a nonlocal resource it is 

marked 'waiting' . 

Riole 1 : The resource R at site ok c.annot be allocated to tran- 
saction T because it is held by T1 , ....Rx. Add an arc from 

T to each of the transactions T1,...,Tk. If there is then a 
cycle formed in the T.IF graph, deadlock has been detected. 
Othervise, for each transaction T' in blocking set(T), send 
the blocking pair (T,T'' to 3orig(T) if oorig(T) =/= S/: and 

to Sorig(T''i if oorig(T') =/= Sk. Form a list of potential 
blocking pairs associated with T. 

Rule 2: A blocking pair (T,T'^ is received. Add an arc from T 

to T' in the 7.’/P graph. If a cycle is formed, then a 

deadlock exists . 

Rule 2.1 : If T' is blocked and Sorig'T) = Sk, then for each 

transaction T" in the blocking set(T', send the blocking 
pair T,T") to 3orig(T"'' if Sorig(T"'' =/= Sk. 

Rule 2.2: If T is waiting and Sorig(T^ = Sk, then for each pc- 

tential blocking pair '"T",!) send the blocking pair (T",T) 
to 3orig(T") if Sorig(T") =/- Sk. Then, discard the poten- 
tial blocking pairs (T",T) and erase the 'waiting' mark of 



Figure 5 shows the actions taken at each site during the execu- 
tion of the DDA following the request by T4 for resource R3* As can 
be seen, the deadlock was correctly detected by site A, in absence of 
fail’ures. If the request message (T4,R3) from site D to site C was 
lost, however, deadlock detection activity would cease. If the block- 
ing pair (T4,T1 ' from site 3 to site D was lost, site A would still 
detect the ieadlcck. If, however, the blocking pair ;TA,T1) from site 
3 to site A was lost, site 3 wciald apply rule 2. "either mile 2.1 or 
2.2 applies, so deadlock detection acrivi''"." would cease. 



oi'be A 



Site C 



Site D 






Z’4,n ’ received. 
'T1 — > T4 

! I 

Deadlock Detected. 



(D4,H3 received) 

1 . 

't;4 > '3]'| 

Blocking 3et^"T) = 

!Tli 

Bend (D4,D1 ) to D 
and A. 

Potential Blocking 
pairs = nil. 

(T4,D1 ) received. 

04 _> 'P'l 



T4 

■^D4 requests R3) 
D. B4 narked waiting 



Figure 3. 



Phis algorithm allows sites of typ^es b, c, d and e, although 
our example does not include a site of type e. If a type b site (one 
having a transaction involved in the deadlock and the site is also 
involved in detection) failed, in our example site A (or site D), the 
behavior of the algorithm is dependent on the time of failure. If 
site A failed before receiving the blocking pair ''14,11 ' , site C would 
recognize the failure, but its action is not specified in the rules of 
the DDA. Site D would not detect the deadlock for the same reson as 
if the message from site B to site A was lost. If, however, the 



failure Dccured after site A received the blocking pair, deadlock 
detection activity would continue (at site Dl but deadlock would not 
be detected. A failure of site D, also a tyme b site, at any time, 
would have no effect on detecting the deadlock in this example. If a 
type c site failed (site 3), it wo’old have no effect on detecting the 
deadlock. If a type d site ^site c’ failed, the time of its failure 
would determine the behavior of the DDA. If it failed ’'eftre sending 



the blocking pair to sites A and D, deadlock detection activity voiold 
cease. If it failed after sending those messages, it ’vould have no 
effect on detecting the deadlock. 

For our example, this algorithm behaved surprisingly simi- 
larly to C-oldman's algorithm in almost all tymes and timings of 
failures. This may Just be an anomaly found in small deadlock cycles, 
because in longer and more complex scenarios, it would anpear tha~ 
more sites would be involved in detection, and tnat there v/culd be 
some duplication of i.nformation. As the number of transactions -end 
resources ; involved in a deadlock cycle increases, more blockins pairs 



and potential blocking pairs will be sent to more sites, i.e.. the 
number of sites detecting the deadlock is increasing 'vith the number 
of transactions involved in the deadlock and with the deadlock topolo- 
gy (or complexity). Thus there will be more chance of a deadlock 
being detected, as more parallel detection activity^ will be in oro- 
gress. It appears, then, that as the site and complexity of deadlock 
increases, the robustness of this algorithmi increases, however, as 
poi.nted out by Gligor and Shattuck. the effect which Gligor and Ghat- 
tuck pcint out of mule 2.2 discarding information too early may have 



some impact on the increased robustness. 

G. CEERI-IARCZ'G 2I3TFI3UTED DEA2LCCX GFTZCTIOII .ALGORITHM. 

In pIBSSC], Cbermarck presents a distributed deadlock detec- 
tion algorithm. A centralised algorithm is presented by Cbermarck and 
Beeri in JBBBSl]. but it is not discussed here because no mention is 
made in ~hat paper about a backup capability if the site cemaining 
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information to one other site. Deadlock detection activity;- at a site 
aay become temporarily inactive 'intil receipt of new information from 
another site. Dbermarck states that in actual practice, synchroniza- 
tion ^ not necessarily precise) between sites would be roughly con- 
trolled by an a^eed-upon interval between deadlock detection itera- 
tions, and by timestamps on transmitted messages, diodes in the graph 
represent transactions, and edges represent a transaction-waits-for- 
transaction situation. A 'String' is a list of T'/FT informa- 
tion which is sent from one site to cne or more sites. A transaction 
may migrate from site to site, in which case an 'agent' represents the 
transaction at the new site(s). A communication link is also esta- 
blished between agents of a transaction. These communication links 
are represented by a node called 'Scternal.' An agent which is expect- 
ed to send a message is shorn in the '-/F graph by 3 — >T, while an 
agent waiting to receive is shovm by T — >S(. Although Obermarck's 
algorithm includes the resolution of deadlocks, only the detection 
part will be considered in this paper. Transaction ID's are network 
unique names for transactions, and are lexically ordered. (For exam- 
ple, T1 < T2 < To). The steps performed at each site are: 



1 . Build a FrfF graph using transaction to transaction wait-for 
relationships . 



2. 


Obtain and add to the existing 
transmitted from other sites. 


F.-/F 


graph 


any 


'strings ' 




a. For each transaction identifi 
node in the F.'/F' if none exists in 


ed in 
this 


a str 
site. 




create a 



b. For each transaction in the string, starting with the 
first vyhich is always 'external'', create an edge to the 
node representing the next transaction in the string. 

Create wait-for edges from 'external' to each node represent- 
ing a transaction's agent which is expected to send on a 
communication link. 

-. Create a 'vF' edge from each node representing a transaction's 



case ' S 



agent which is waiting to receive from a communication link, 
to 'external. ' 



5- Analyze ohe graph for cycles. 

6 . After resolving all cycles not involving ' external ' , if the 
transaction ID of one node for which 'external' waits is 
greater than the Transaction ID of the node waiting for 

'external', then 

a. Transform the cycle into a string which starts with 

'external', followed by each transaction ID in the cycle, 
ending with the transaction ID of the node waiting for 

' external ' . 

b. Send the string to each site for which the transaction 
terminating the string is waiting to receive. 

In his proof of correctness, Obermarck shows how the algo- 
rithm can detect false deadlocks because a string received at a site 
may no longer be valid when it is ’osed. He discusses two methods of 
handling false deadlocks; treat them as actual deadlocks (if they ion't 
occur too often ' , or verify them by sending them around the ney//ork 

and have each site verify them. 



A 3 






r^T' >T'- 



rigure 4 shows a global picture of the system, including the 
comm’unication li.nks established bem^een agents, for the initial condi- 
tions of our example. The agents of T'' at sites 3 end 

03.ffe " 9 



nave 



performed work (used R2 and RJ'' , and are ••/aiding for dhe next request 
from T1 at site A. T1 at site A is waiting for its agent at site D, 
which is in resource-wait for T4* figure 5 sho’^s the actions of this 



algorithm in an environment of no errors, 
fully detects the deadlock. 



Site A 



Site E 
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An agent of 
21 is formed 



As can he seen, it success- 

Site D 
11 requ€ 



^ ,3,1: each site starts deadlock detection and builds IT graph. 
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5: list elementary cycles 
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S:{->T4->11->SX ZX->11 ->14->SK 

6: form string 
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Send to A. 
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5: form string 
; EX. 11, 11 ) 
Send to D . 
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Dbermarck assumes that messages sent are received. Ihis is 
essential to the correctness of this DDA, because it is easy to see 
what -lappens if a message is lost. If the string 'Zlli.l'! ' from, site 
1 to .4. or from A t.o D '/ere lost. iea.dlock detection acti''i~^ /^ul 









cease -./ichou:; defecting the deadlock. The use of agents to represent 
transactions which have migrated to other sites allow this DDA to have 
nodes of tyrjes a or b, if we substitute 'agents' for '‘transactions' in 
our definitions at the beginning of this section. Site B would be an 
example of a type a site, while the other three sites ‘.'/ould all be 
type b sites. 

A failure in site 2 ‘.vould have no effect on the behavior of 
the IDA. A failure a":; sites A, 3 or 3 '.vould either have no effect, an 
lAndetermined effect, or cause deadlock detection ?,ctivi 07 to cease, 
depending cn the tine of the failure. For example, if site C failed 
before sending the string ' to site A, deadlock detection 

activity would cease. If site A (or failed before the string 
was sent to then, the transmitting site would recognise the 
fail’ure, cut its action in that eventuali’ty is not included in the 
steps of the DDA. If site 1 failed after sending the string, the 
detection activity would continue, and the deadlock would be detected. 

-his IDA appears to be potenti-ally more rcbi^st than the pre- 
vious trwo. Bach site contains and retains more information in its AT 
graph, and all sites start detection activity simultaneously, and 
potentially stay invol’'‘ed for the entire detection process. The use 
of the lexical ordering of nodes -.vas for optimisation of the number of 
messages transmitted. If tnis constraint vrere lifted, the strin.ts 
would be sent to all sites involved from -all sites in "vnioh a cycle 
existed. In our example, this would have allowed sites A and D to 
simultaneous l 3 /' detect deadlock. Ihe IDA would be clearly m.ore robust, 
but the overhead ‘.vOuld be treater. In its existing form, this IDA’s 
robustness is similar to the previoits 'algorithms because it is essen- 
tially sequentially de*:ectins ~he deadlock. 



D. THE ALGCEITHT'! OF TSAI AIID 3ELFCRD. 



In [TSA82], Tsai and Selfcrd present a distributed deadlock 
detection algorithm. They utilize a "Reduced Transaction-Resource" 
(RTR) graph, which contains only a subset of the transaction resource 
graph, but has all relevent 1./? edges, lodes in the RTR graph can be 
transactions or resources. The algorithm uses a concept the authors 
c.all a "reaching pair", which is the basic lanit of information passed 
from site to site. If a path TiTJ...Tn can be formed by following 
edges, and if there is a request edge (Tn,Rm), then Ti "reaches" Rm, 
and (Ti,Rm) is a "reaching pair." Five types of messages are sent 
between sites: reaching messages, nonlocal request messages, alloca- 
tion messages, release-request messages, and releasing messages. The 
non-local request messages include a list of all resources currently 
held by the requesting transaction. Five different types of edges are 
distinquished in the RTR graph: requesting edges, allocation edges, 

edges, resource reaching edges and transaction reaching edges. A 
global timestamp is also used to establish an ordering of events. 
This timestamp is used on allocation, request and reaching messages, 
and on allocation and reaching edges in the RTR graph. The notation 
used in the algorithm is: 

TS(M): timestamp of a message 

TS(C): current system time 

TS(A) : timestamp of an allocation edge 

TS(R): timestamp of a reaching edge 

=/=: not equki to 

Sorig: Site of origin 

The steps of the algorithm !!as executed at site Sk) are: 

Step 1 : Ja transaction T enters the system requesting a nonlocal 

resource R| Add request edge (T,R) to RTR graph. Send re- 
quest message (T,R',R,TS) to Sorig(R;, where R' is the set 
of all resources allocated to T. and ZS('"^ = TS(T'. R' has 
each TS(A) attached, and R' is empty if T holds no 
reso’Jiross . 



:axe 



step 1a: {A transaction S releases a nonlocal resource R| Zrase edge 
(?.,1) in the RSR graph. Send a release-request nessage<^R,l) 
to Sorig(R) . 

Step 2: {a transaction T enters system requesting local resource Ri 

C-o to step 4. 



Step 2a: {A transaction T releases a local resource R) Erase edge(R,T) 
in R?R graph. If there is any transaction T' waiting for R, 
then begin 

Add allocation edse (R,2') to RIH rraph with 2S(A) = 
IS ( C) . Send allocation message ' R , I ' , IS 1 with IS ( !! ) = 
IS(C) to Sorig(I') if Sorig,!'} =/= Sk. end. 

Step 3: fA request message (I,R'.R,IS) is received! Add allocation 

edges (Ri,I' for each Ri in R' to RIR graph, lo to step 1. 

Step 3a: jA release-request message 'R,I'' is received! Erase alloca- 
tion ed^ (R,I) in RIR graph. Send releasing message (R,I) 
to Sorig(I). If there is any transaction I' waiting for ?., 
then begin 

Add allocation edge (R»I') to RIR graph with I3(Al = 
IS(G). Send allocation message (R,I',IS) to Sorig(I') 
if Sorig(I') =/= Sk. end. 



Steo 4: If R is not held by any transaction, then beein 

Add allocation edge (R,H 'with IS(A')=IS(C) to RIR 
graph. If Soris(I) =/= Sk, then send .an alloation m.es- 
sage (R,I,ISl -with IS(M)=IS(C) to SorigdN end. 
else begin 

Add requesting edge (I,R) to RIR graph. Suppose R is 
held by transaction I'. Add edge !l,I’'' to RIR graph. 
If there is a cycle, deadlock has been detected, else 
go to step 5 . -nd . 

Step 5: {reaching message generation step! I- there are two edges 

(I,R) and {I»I') added to the graph, and if II'... I" is any 
path obtained by following the l./R and transaction reaching 
edges, then set X =R" if I" has outgoing edge to R", else 
set X = R. For all transaction li in RIR graph reaching X 
via I, do begin 

If li holds any resource R' v/ith Sorig(Ii) =/= 
Sorig(R' ; and ScrigiR*') =/= Sk. then send a reaching 
message ,Ii,X.IS) to 3orig(R'''. If 3crig(Ii1 =/= Sk 
and li =/= I, then send a reaching message ^Ii,X,IS) to 
3orig(Iiy. If Sorig(Ii) =/= Sk and li = I and X = R" 
then send a reaching message 'Ii,X,IS' to oorig''Ii''. 
Ihe IS in the reaching message is set to IS(C) if trig- 
gered by a local request, and set to IS(M) of the non- 
local request or reaching message otherwise. 



Step 6: 



kiwi 



allocation message {R,I,IS) 
the graph, then begin 
Erase allocation edse 
(i",R) -with is;?! < IS{:0 
edge ^1,1'. and transact 



is received! If R is 'an entg;/ 

and all reachine edges 
•and the ccrresronding X.v’R 



“hey exist, where '2' =/= 2. Change reauestine edge 

(?,R) to allocation edge {R,2) -.^ith CS('a) = CS(:i) if 
'1,R) exists, and for each resource reaching edge 
'C",?.}, add the transaction reaching edge [2" ,2) . If 
Sorig(I) = 3k, wake up transaction I. end. 

Step 6a: \A releasing message (R,I) is received} If Sorig(T) = Sk, 

v/ake up transaction 2. 

Step ?: {a reaching message (I,R,IS) is received) If there exists an 

allocation edge (R,I') in the graph 'vith IS(M) < IS(A) and 
2' =/= I, then skip this step, else hegin 

Add resource reaching edge 'I.R) to the RIR graph. If 
R is held by transaction I', then add the transaction 
reaching edge (T,T') to the ^raph. If there is a cycle 
in the graph, there is deadlock (go to step other- 
wise go to step 5- ■5nd. 

Step 3: {a deadlock has been detected) lake appropriate action. 



Figure 6 shows the starting V/R graphs and the actions of the 
DDA resulting from the request by transaction lA for resource RR. An 
important item to note is that as soon the request is made, step 1 
adds s'ufficient information to the v/? graph to detect a deadlock, but 
does not check for deadlock, so the request is sent to site C and the 
algorithm continues. Ihe obvious thing to do would be to add a check 
for a deadlock cycle in step one, but on closer analysis, this check 
may lead to detection of false deadlocks 'if, for example, H had just 
released R3 but the message had not yet been received by site D.) 
Therefore the algorithm! in its present form will be analysed. The 
only message sent by this algorithm in this example is the request 
message (T4, iR4) ,R3,t6) . If it was lost, “he current algorithm! would 
cease detection activity without detecting deadlock. In ohis in- 
stance, if the algorithm checked for deadlock in step , it would have 
been detected ’vith no messages recuirsd. 
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Por this DDA, sites can be cf t;/pe b, d or e. Sites A and D 
are type b and sites 3 and C are type d. This example has no tyce e 
sites, but step 5 of the algorithm could send reaching messages to 
sites not involved at all . Those sites uould execute a step or tvo of 
the algorithm, but not be intimately involved in the actual deadlock 
detection. In this example, a fail’ore of sites A or 3 'types b and i 
respectively) would have no effect on the detection of the deadlock. 
The effect of a fail'’ore of site C before the reaching message was sent 
to it cannot be determined because the DDA includes no instructions 
for that event. A fail'ore of site G after receiving the reaching mes- 
sage would result in a cessation cf detection activity’. If the algo- 
'/0rs mo — i. 3c oo 3, b ^ 



site C at any time -.TOuld have no effect on deadlock detecnion. The 
timing of the fairore would also determine the behavior of the DDA if 
site D failed. If site D failed before sending the request message, 
detection activity would cease, while if the message had been sent, 
deadlock would still be detected. 

7or our example, this DDA appears to be about the same level of 
robustness as the other algorithms, except that each site contains and 
retains more information than in other DDA's. Ihis indicates that it 
should be more robust. The algorithm in the case of our example was 
able to detect the deadlock with only the resource request message. 
As deadlock cycles become more complex, it appears that this algorithm 
will also become more robust, even more so than Obermarck's, because 
this DDA retains more information, and it will send reaching messages 
to any site potentially involved in the deadlock. Detection activity 
will occur simultaneously in those sites receiving reaching messages. 
The impact of the inclusion of a cycle detection in step 1 may have 
adverse effects on the correctness, but it might greatly enhance the 
robustness of the DDA. 



lY. CONCLUSIONS 



The algorithms discussed in the previous section c.an be loosely 
ranlced by their robustness. Coliman's algorithm! is the least robust, 
because it is always executed sequentially (unless the requests occur 
simultaneously, as discussed previously) . Thus it is always dependent 
cn a single node. Obermarck's algorithm starts deadlock detection 
simultaneously at all sites, and subsequently passes information in a 
lexical manner because Df the message optimisation. Dor our example, 

res'olted in a sequenmial detection, althougn for larger leadlock 

oa^e 25 



this 



arser 



cycles, it should have some parallel detection activity occuring. The 
Menasce-'tuntz algorithun starts detection at the site where the 
deadlock occured, and deadlock detection is subsequently conducted at 
sites which are potentially involved. The Tsai-BeLford algorithm is 
invoked each tine a resource is requested. Deadlock detection can 
appear concurrently at all sices potentially involved in the cycle. 
It appears more robust than the Menasce-r-luntz algorithm because more 
information is held at each site. 

Our analysis supports the rather obvious conckcsion that robust- 
ness is inversely related to it's cost. The Tsai-3elford algorithm 
appears more robust than Obemarck's algorithm, for example, but it 
maintains larger W graphs at each site, and is invoked each tine a 
resource is requested, in order that the W graphs contain sufficient 
information. 

Bor the example we ’used to analyse the four algorithms in section 
3, the behavior of each of those algorithms in the presence of errors 
is alnort identical. Because our deadlock cycle only involved 2 tran- 
sactions, those algorithms which are potentially more robust in the 
presence of larger cycles did not have time to develop their robust- 
ness. In other words, for a short deadlock cycle, all the algorithms 
converged within approximately the same length of time (^*'0 or three 
iterations . ) Short cycles of length 2 or 3 are more probable in exist- 



ing applications, sc all the above algorithms are approximately eq'ual- 
ly robust in current applications. In future applications (informa- 
tion utility programs, for example!', however, we expect a much higner 
probability of more complex deadlock cycles, which will require a more 
robust DBA. Donversely, however, as the number of transactions '-and 



sites, increases, it wil_ 



imncrtant to 'ise a minimum cost 









progress on a new robust distributed deadlock 



-fork is currently in 
detection algorithm. 
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